In many computing systems, low level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high level software executing on the computing system. In some computer systems, this low level instruction code is known as the Basic Input/Output System (“BIOS”). The BIOS provides a set of software routines that allow high level software to interact with the hardware components of the computing system using standard calls. BIOS-compatible firmware implementations may be referred to herein as “legacy BIOS.”
Because of limitations of the BIOS utilized in many PC-compatible computers, a new specification for the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been proposed. The new specification is called the Extensible Firmware Interface (“EFI”) specification and is available from INTEL CORPORATION.
The EFI specification describes an EFI environment that provides an interface between the operating system and the system firmware. In particular, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI specification provides protocols for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.
In general, EFI-compatible systems are built from a collection of EFI drivers. Drivers may be responsible for managing a device (a device driver), a bus (a bus driver), or for implementing a particular technology (a technology driver). It may be necessary to develop one of each type of driver to implement support for a single device type. For example, in order to implement support for small computer systems interface (“SCSI”) storage devices, it is necessary to develop an EFI SCSI bus driver, an EFI SCSI controller chipset driver, an EFI SCSI device block input/output driver, and potentially other drivers.
Typically, the manufacturer of a device will provide the appropriate drivers for the device in the particular environment. For instance, the driver for a SCSI controller chipset is typically provided by the manufacturer of the controller. However, EFI-compatible drivers are not always available from the device manufacturer. This is particularly true in the case of a new firmware environment, such as EFI, wherein support is initially very limited. On the other hand, hardware support is almost always available for legacy BIOS environments. This hardware support comes in the form of initialization and runtime firmware contained on a BIOS option read-only memory (“ROM”) located on the device itself.
Legacy BIOS is designed to execute available option ROMs and to supply the necessary interrupt servicing functions. EFI, in contrast, is not designed to directly execute the option ROM firmware. EFI operates in the CPU protected mode execution environment while option ROMs are designed to be executed in the CPU real mode execution environment. Many legacy BIOS option ROMs also require hardware interrupts, which the EFI environment does not support. For these reasons, many devices that implement firmware support using option ROMs are unusable within an EFI environment if no EFI-compatible driver is available.
In order to enable the EFI firmware executing in the CPU protected mode execution environment and the option ROM executing in the CPU real mode environment to communicate and exchange data, an interrupt thunk driver has been developed. The interrupt thunk is designed to switch the CPU execution mode between protected mode and real mode, and to utilize a buffer to transfer data between the two modes. While utilization of an interrupt thunk does allow execution of option ROM firmware within an EFI environment, there are still certain categories of devices that remain inaccessible. For instance, devices supported by option ROMs compatible with the BIOS boot specification (“BBS”) are not accessible.
The BBS defines a feature within legacy BIOS that creates and maintains a list of all of the initial program load (“IPL”) devices found in the system and stores this list in non-volatile memory. IPL devices may be mass storage devices, network devices, or other types of devices. The BBS also defines several phases of operation for a compatible option ROM. For instance, a BBS-compliant SCSI peripheral component interconnect (“PCI”) option ROM utilizes an initialization phase, a connection phase, and a run-time operation phase. In the initialization phase, the option ROM performs the controller hardware initialization and scans the bus to identify any connected devices. In the connection phase, the option ROM executes connection code for each of the devices and inserts the appropriate entry points for accessing the devices into an interrupt vector table. In the run-time operation phase, the option ROM receives and responds to requests to read and write data on a connected device. These three phases are interdependent in that run-time operations are not possible prior to the connection phase, and the connection phase is not allowed prior to the initialization phase.
The EFI specification requires controllers to remain in the initialization phase until the system is requested to perform a legacy boot. As a result, run-time operation is not possible prior to booting a legacy operating system (“OS”). Therefore, devices supported by BBS-compliant option ROMs, such as SCSI hard drives, are not accessible from within the EFI environment. It is with respect to these considerations and others that the various embodiments of the invention have been made.